Wine is drunk, a computer is serviced, a record is played, a pin is just kept. Each type has asked for something the others don't need — a drinking window, a service clock, a working state, parts inside parts. The risk is obvious: sixteen types become sixteen small apps sharing a tab bar. This page proposes the rules that stop that, and shows one screen rendering five types without changing shape.

Every dashed box is a slot. The type fills it or hides it; it never adds a box, moves one, or invents a control. Switch types and watch what changes — and what can't.

Today a type is a YAML manifest. Coherence is mostly a matter of what that manifest is allowed to contain. This is the proposed boundary — the left column is the entire vocabulary a type has; the right column is what it can never touch, no matter how good the reason.

The test for any proposed type, official or community: can it be written in the manifest with at most one new primitive and zero new screens? Wine passed with yearRange. Retro computers passed with composite. Anything that fails is either two types or a feature.

Slots and swatches keep the app coherent; they also risk making a cellar and a crate feel like the same spreadsheet. So a type may declare up to two signatures: a small, opinionated rendering of a field it already owns — the drinking window drawn as a gauge, bottles left drawn as bottles. Not a new control, not new data, not a screen. A noun, drawn bigger.

Every kind is one control, built once, tested once, exported once. When a proposal asks for something not on this table, the answer is "which existing kind is closest?" first, and "which second type would need it?" second.

The proposal system is where coherence is most at risk — sixteen careful types can be undone by two hundred careless ones. The AI pass checks the mechanics; the human pass checks the taste. Both use this list, and it's shown to the proposer before they start.

Worth asking, because the premise is sound: the most important fact about an object is not in the same place for every hobby. A bottle's window matters more than its label condition; a machine's working state matters more than its cosmetics. If the order were type-owned, each hobby could lead with its own truth. Three candidates, then the reason I'd still keep the order fixed.

Not because it's wrong per type — it's right per type. It's wrong per user, and the asymmetry is the whole argument: the benefit of a better order is collected once, when you learn a type. The cost of a shifting order is paid on every screen, forever. A mixed collector flicks between a bottle and a record twenty times an evening; each flick becomes a re-read. And the app's own pitch — one place for everything — is the pitch most damaged by it.

Cheap way to be sure: ship A, log how often people hunt (time-to-first-scroll on the item screen, per type). If machines and bottles scroll measurably more than records, that's an argument for C's dials — it is never an argument for B.

You were right that the vinyl ladder is the reusable one — and it's more reusable than it first looked. Almost every collectible has an ordered notion of condition; what differs is only the steps, the number of axes, and whether the bottom of the scale means ruined or absent. All three are already in the YAML. So the ladder takes nothing new:

Two maximum, both bound to fields the type already declares, both from the kit. Where a type only earns one, it gets one — an empty second slot is not a gap.

One renderer leaves and one arrives. Triptych is gone — it was a one-customer renderer doing the ladder's job. Set arrives with eleven customers on day one, which is more than any renderer in the kit except the ladder: it renders "which of the N you have" from a series field, and it is the single most requested thing in every set-collecting hobby.

Six renderers still cover twenty types, and the two on the exception clause are the two I'd cut first if the count ever crept toward ten. Section 03's rule 2 stands: a type binds, it never paints.